Various communication terminals and devices are available today that are capable of packet-based multimedia communication using IP (Internet Protocol), such as either fixed or mobile computers and telephones. Multimedia services typically entail transmission of encoded data representing media in different formats and combinations. For example, an IP terminal may exchange audio information as well as visual information with another IP terminal, or may download multimedia in any format from a content server.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard for handling multimedia services and sessions in the packet domain. An IMS network basically controls multimedia sessions for IP terminals based on IP transport, regardless of access technology. For example, plural different access networks may be attached to one and the same IMS network.
FIG. 1 is an exemplary schematic illustration of a basic network structure for providing multimedia services for a mobile IP terminal A by means of an IMS service network. Terminal A is connected to a radio access network 100 and communicates with another IP terminal B in a communication session involving one or more multimedia services. The radio access network 100 is connected to an IMS network 102 which handles the session with respect to terminal A. Alternatively, terminal A may communicate with a content server for downloading some media content.
The session illustrated in FIG. 1 is managed by specific nodes in the IMS network 102, here generally referred to as “session managing nodes” 104. These nodes typically include S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function). IMS network 102 also includes one or more application servers 106 for enabling various multimedia services and a database element HSS (Home Subscriber Server) 108 storing subscriber and authentication data, among other things. The various functions of network elements 104-108 are generally known in the art and are not necessary to describe here further to understand the context of the present invention.
A signalling protocol called “SIP” (Session Initiation Protocol) is used for controlling sessions in IMS networks. Standard SIP messages can thus be used by IMS systems and IP terminals or devices to establish and control multimedia sessions. For example, a message defined in SIP is called “INVITE” which a terminal can send to another party during a set-up procedure to initiate a session, e.g. when a multimedia application has been invoked in the terminal.
In SIP, an additional protocol is used called “Session Description Protocol SDP”, for describing multimedia sessions by means of an SDP message, which can be embedded as a self-contained body within SIP messages. SDP can thus be used by terminals to provide information regarding their specific capabilities and preferences, in order to specify and negotiate session parameters for a forthcoming multimedia session, as is well-known in the art. The above-mentioned SIP INVITE message typically includes the embedded SDP message with information on one or more required codecs (coders/decoders) as well as other communication parameters needed for the session, such as an IP address and a port number.
According to 3GPP, it is required that a subscribing communication terminal accessing an IMS network has access to an SIM (Subscriber Identity Module) application valid for IMS, generally referred to as “ISIM” (IMS SIM), in order to provide necessary authentication and subscriber data to an operator of the IMS network. Today, only such terminals with ISIM capability are allowed to access an IMS network.
An ISIM application is typically installed on a Universal Integrated Circuit Card (UICC), analogous to the well-known SIM card for GSM terminals. Terminals equipped with ISIM are called IMS terminals. Among other things, an ISIM stores an IMS Private Identity referred to as “IMPI” and at least one IMS Public Identity referred to as “IMPU”, which are both known to the IMS network. IMPI is used for authentication and is not to be disclosed to third parties, whereas IMPU can be used by anyone to identify subscribers and/or their equipment when participating in IMS services, as analogous to an e-mail address or a telephone number. The intention is that each IMPU is associated with an IMS service profile.
While the IMS concept was primarily conceived to enable multimedia services for mobile IP terminals, it can be used regardless of access technology, as mentioned above. In the European Telecommunications Standards Institute (ETSI), a working group called TISPAN (Telecom and Internet Services and Protocols for Advanced Networks) is currently working with the adoption of IMS in fixed networks. It is now also desirable to provide such IMS-based services for a variety of IP terminals connected to a local or private network, particularly a residential or office network environment using, e.g., conventional LAN (Local Area Network) equipment and protocols. The generic term “private network” will be used in the following description to represent any such networks, including LAN, WAN (Wide Area Network) and WLAN (Wireless Local Area Network). Further, the term “home device” will be used for any terminal within the private network capable of IP communication.
A private network may include fixed or wireless communication devices that are not IMS enabled, even though they may be “SIP enabled”, while other communication devices in the private network may be neither IMS enabled nor SIP enabled. For example, such plain devices may include fixed and cordless telephones, as well as PC's and so-called Set Top Boxes (STB) for television sets. The large amount of such existing devices makes it desirable to provide for an inter-working solution between non-IMS devices and the IMS network, to enhance the market for multimedia services.
In order to provide IMS services to non-IMS enabled devices in a private network, a multimedia gateway referred to as a “Home IMS Gateway, HIG”, has been defined that can act as an IMS enabled terminal on behalf of any home device in the private network. This type of Home IMS Gateway is described in WO 2006/045706 (Telefonaktiebolaget LM Ericsson). Among other things, the HIG includes an SIP “Back-to-Back User Agent” (B2BUA) for communications between SIP enabled but non-IMS enabled devices and the IMS network. The B2BUA is equipped with an ISIM application and handles IMS signalling on behalf of SIP devices, such that all signalling concerning an SIP device is associated with the corresponding IMPI on the ISIM application. For example, an SIP enabled home device may send an SIP REGISTER message to the HIG, containing only an SIP identity. The HIG will then translate the message into an IMS REGISTER message that contains both an IMPI and an IMPU, according to regular IMS procedures.
A typical scenario for using the HIG is generally outlined in FIG. 2, illustrating a private or “home” environment 200, such as a family residence or an office, that contains a plurality of different home devices linked together in a private network 202. As illustrated here, these devices may include a wireline telephone, a cordless telephone, a TV set, a server and a PC, and these will be simply referred to as “home devices” hereafter.
The private network 202 includes a conventional residential gateway RGW 204 which is connected to an external access network 206, providing a communication link for media M to and from the devices in network 202. Although not specifically illustrated here, the RGW 204 typically includes NAT (Network Address Translation) and firewall functions, and also a local DHCP (Dynamic Host Configuration Protocol) server providing private IP addresses to the devices, as is well-known in the art.
The private network 202 further includes an HIG 208 providing a connection to an IMS network, here represented as an IMS core 210 containing an HSS 212, among other things. The HIG 208 is equipped with interfaces towards the different types of devices for signalling, using device-specific protocols. In the above-mentioned document WO 2006/045706, the basic functional HIG architecture, including various interfaces, protocol translation and gateway functions, is described in detail. In practice, the described HIG functionality may be implemented as a separate node, or in an RGW, or even in an IMS enabled terminal. However, it is considered as a separate functional unit in this description regardless of implementation.
In the HIG 208, identity information 214 is stored for each of the devices in the private network 202, typically including the above-mentioned IMPU, which is valid for accessing the IMS core 210 where the same identity information is also stored as subscriber information 216 in the HSS 212, as indicated in the figure. The above-mentioned WO 2006/045706 outlines how different combinations of IMPI and IMPU can be used in this context. Thus, each home device in network 202 has been assigned a local identity that is associated with a specific IMS identity such as an IMPU used for representing one or more devices, or the IMPU of HIG. The identity information 214 is typically stored in an ISIM application implemented in the HIG 208.
Thus, when a device in network 202 sends a request for an IMS service, using a protocol within its capability, HIG 208 identifies the device by means of its local IP address, and retrieves the corresponding IMS identity 214 of the device itself or of the user logged on to that device. Then, HIG 208 can translate the received service request and create a valid SIP-based IMS request (e.g. SIP INVITE) on behalf of the device, using the retrieved IMS identity 214. HIG 208 will then set up a session for the device by communicating suitable SIP messages with the IMS core 210, accordingly.
In a similar manner, an incoming call involving an IMS service, which may be addressed to one of the devices or generally to the private home or office, can be set up by the HIG on behalf of a device using an IMS identity 214 associated with the device or HIG 208. The call can then be routed to the called device over the RGW 204 in order to communicate media M. In this way, the IMS core will perceive the device in network 202 as an IMS enabled device, even when this is not the case, and the device will use the HIG 208 as a proxy for accessing services offered by means of the IMS network.
The IMS network operator typically hands out IMS identities which are registered in the IMS network as subscriber information stored in the HSS 212. According to different alternatives, a valid IMS identity and necessary authentication data may be registered in the HIG for each home device in network 202, or one or more common IMS identities may be shared by plural home devices for use on a session basis.
Non-IMS devices may communicate by means of the HIG 208 using an architecture according to UPnP (Universal Plug-and-Play) which is developed in a multi-vendor collaboration for establishing standard device control protocols. UPnP thus provides peer-to-peer connectivity for communication between any types of devices in a private network, regardless of access technology, operating system, programming language, format standard and communication protocol of the device. The UPnP technology is based on Internet standards such as IP, TCP, UDP, HTTP, and XML, and can use any transport medium such as a telephone line, Ethernet and different types of wireless. UPnP defines base protocol sets for each type of device.
Further, UPnP supports an automatic “discovery” process, also referred to as “pairing”. Using the discovery process, a home device can dynamically join a private network, obtain a private IP address, announce its name and IP address, and provide its capabilities to other devices upon request. In this way, each home device in the private network can also obtain information on the presence and capabilities of other devices in the network.
DLNA (Digital Living Network Alliance) is a new technology developed by leading manufacturers of electronic consumer equipment for acquiring, storing and accessing digital content from any devices in a home network, e.g. music, films and images. Such DLNA devices incorporate a networking component called “Device and Service Discovery and Control” for automatic self-configuration of networking properties such as private IP addresses i.e. the above-mentioned discovery functionality. To accomplish this, DLNA uses a standardised UPnP protocol according to the UPnP Device Architecture, Version 1, providing simple and effective device networking in the home.
In addition to the communication of different home devices within the private network, it is also desirable to access the private network remotely, i.e. such that a remote device located outside the private network can communicate with home devices within the private network, in the same manner as when located inside. In WO 2006/079891 (Nokia), a solution is described for setting up a VPN (Virtual Private Network) tunnel as a data transport channel for remote UPnP access, e.g. using IPSec (IP Security). Presumably, DLNA will utilize the UPnP remote access architecture to also allow remote DLNA devices to access the home network.
However, home devices in a private network use private IP-addresses (e.g. 10.0.x.x, 192.168.x.x and 172.x.x.x) for communication within the network. Such local network addresses can only be used for routing inside the private network. Once a home device has executed the discovery process in a private network when located inside the network, it has knowledge of the IP-address, name and capabilities of other home devices. Using this knowledge, these devices can exchange media content inside but not outside the private network. Thus, should the home device move out of the private network and connect to some public access network, it can no longer interact with the other home devices in this manner.
The solution for remote access described in the above-mentioned WO 2006/079891 requires the use of IP address resolution based on FQDN (Fully Qualified Domain Name) and dynamic DNS (Domain Name server) technology. Therefore, it is necessary to have access to a dynamic DNS client in the private network. Moreover, this solution is “device centric” by authenticating the current device being used, rather than the user of that device.